Machine-to-machine (M2M) technologies allow devices to communicate more directly with each other using wired and wireless communications systems. M2M technologies enable further realization of the Internet of Things (IoT), a system of uniquely identifiable objects and virtual representations of such objects that communicate over a network, such as the Internet. IoT may facilitate communication with even mundane everyday objects, such as products in a grocery store, and thereby reduce costs and waste by improving knowledge of such objects. For example, stores may maintain very precise inventory data by being able to communicate with, or obtain data from, objects that may be in inventory or may have been sold. As will be appreciated, the IoT has the potential to include many millions of devices.
oneM2M includes technical specifications which address the need for a common M2M Service Layer that can be readily embedded within various hardware and software, and relied upon to connect the myriad of devices in the field with M2M application servers worldwide.
FIG. 1 shows an oneM2M architecture. “oneM2M-TS-0001 oneM2M Functional Architecture-V-1.6.1” hereafter “oneM2M functional architecture” defines a Service Layer called a Common Service Entity (CSE) 102. The purpose of the Service Layer is to provide “horizontal” services that can be utilized by different “vertical” M2M systems and applications, such as e-Health, fleet management, and smart homes.
The CSE 102 supports four reference points. The Mca reference point interfaces with the Application Entity (AE) 106. The Mcc reference point interfaces with another CSE 110 within the same service provider domain and the Mcc′ reference point interfaces with another CSE in a different service provider domain 104. The Mcn reference point interfaces with the underlying network service entity (NSE) 108. An NSE provides underlying network services to the CSEs, such as device management, location services and device triggering. CSE 102 contains multiple logical functions called “Common Service Functions (CSFs)”, such as “Discovery”, “Data Management & Repository”. FIG. 2 illustrates the CSFs under development at oneM2M.
The oneM2M architecture enables the following types of Nodes:
Application Service Node (ASN) is a Node that contains one CSE and contains at least one Application Entity (AE). Example of physical mapping: an ASN could reside in an M2M Device.
Application Dedicated Node (ADN) is a Node that contains at least one AE and does not contain a CSE. There may be zero or more ADNs in the Field Domain of the oneM2M System. Example of physical mapping: an Application Dedicated Node could reside in a constrained M2M Device.
Middle Node (MN) is a Node that contains one CSE and contains zero or more AEs. There may be zero or more MNs in the Field Domain of the oneM2M System. Example of physical mapping: a MN could reside in an M2M Gateway.
Infrastructure Node (IN) is a Node that contains one CSE and contains zero or more AEs. There is exactly one IN in the Infrastructure Domain per oneM2M Service Provider. A CSE in an IN may contain CSE functions not applicable to other node types. Example of physical mapping: an IN could reside in an M2M Service Infrastructure.
Non-oneM2M Node (NoDN) is a Node that does not contain oneM2M Entities (neither AEs nor CSEs). Such Nodes represent devices attached to the oneM2M system for interworking purposes, including management.
The possible configurations of inter-connecting the various entities supported within the oneM2M system are illustrated in FIG. 3.
Registration
An AE on an ASN, an MN or an IN performs registration locally with the corresponding CSE in order to use M2M services offered by that CSE. An AE on an ADN performs registration with the CSE on an MN or an IN in order to use M2M services offered by that CSE. An IN-AE performs registration with the corresponding CSE on an IN in order to use M2M services offered by that IN CSE.
The CSE on an ASN performs registration with the CSE in the MN in order to be able to use M2M Services offered by the CSE in the MN. As a result of successful ASN-CSE registration with the MN-CSE, the CSEs on the ASN and the MN establish a relationship allowing them to exchange information.
The CSE on an MN performs registration with the CSE of another MN in order to be able to use M2M Services offered by the CSE in the other MN. As a result of successful MN-CSE registration with the other MN-CSE, the CSEs on the MNs establish a relationship allowing them to exchange information.
The CSE on an ASN or on an MN perform registration with the CSE in the IN in order to be able to use M2M Services offered by the CSE in the IN. As a result of successful ASN/MN registration with the IN-CSE, the CSEs on ASN/MN and IN establish a relationship allowing them to exchange information.
Following a successful registration of an AE to a CSE, the AE is able to access, assuming access privilege is granted, the resources in all the CSEs that are potential targets of request from the Registrar CSE.
The followings are some registration regulations specified in the oneM2M Functional Architecture:                An AE shall not be registered to more than one CSE (ASN-CSE, MN-CSE or IN-CSE).        An ASN-CSE shall be able to be registered to at most one other CSE (MN-CSE or IN-CSE).        An MN-CSE shall be able to be registered to at most one other CSE (MN-CSE or IN-CSE).        An MN-CSE shall be able to support only a single registration towards another MN-CSE or an IN-CSE.        A concatenation (registration chain) of multiple uni-directional registrations shall not form a loop. E.g. two MN-CSEs A and B, cannot register with each other. Three MN-CSEs A, B and C, where A registers to B, and B registers to C, then C cannot register to A.Procedure of Accessing Resources (Multiple Hops)        
FIG. 4 shows the existing procedure of an originator accessing a resource at the Hosting CSE, which is multiple hops away.
The Originator of the Request accesses a resource. The Originator of the Request may be an AE or a CSE. Registrar CSE, Transit CSE(s) and the Hosting CSE are different entities.
Registrar CSE:                Forwards the Request to a Transit-1 CSE (e.g. MN-CSE) that the Registrar CSE is registered with, if configured through policies to do so; or        Forwards the request to an IN-CSE if the Registrar CSE is registered with IN-CSE and if configured through policies to do so.        
Transit-N CSE:                Forwards the request to the Hosting CSE if it is registered with the Hosting CSE; or        Forwards the Request to another Transit-(N+1) CSE (e.g. another MN-CSE) that the Transit-N CSE is registered with; or        Forwards the request to an IN-CSE if the Transit-N CSE is registered with the IN-CSE.        
In case the Request reaches the IN-CSE, the IN-CSE:                Performs the processing defined under ‘Hosting CSE’ below if the targeted resource is hosted on IN-CSE;        Forwards the request to another IN-CSE if the resource belongs to another M2M SP; or        Forwards the request to the Hosting CSE if the latter is known (e.g. announcements) by the IN-CSE.        
Hosting CSE checks the Access Control Privileges for accessing the resource and depending on the expected result content respond with a success or failure Response.
M2M Requests Routing Policies
CSEs 102 can use policies to govern routing of M2M requests to the next hop towards its target. Routing, through these policies, can be based, for example, on the target CSE, target M2M domain, specific types of resources if applicable, priority of a request, etc.
These policies are not defined in the oneM2M Functional Architecture. It is the responsibility of M2M SP and the CSE administrator to ensure the appropriateness of these policies for routing purposes.
oneM2M Service Architecture
The M2M Service Architecture described in the oneM2M Functional Architecture augments the oneM2M Functional Architecture by specifying M2M Services provided to M2M Application and M2M Service Providers.
The following components are defined as shown in FIG. 5. Service Exposure Component 504 exposes services to AEs 106. Network Service Utilization Component 506 consumes services from the NSE 108. Remote Service Exposure Component 502 connects Services from different M2M environments.
Internet Routing Protocols
Routing Information Protocol (RIP) was one of the earliest intra-AS Internet routing protocols (Interior Gateway Protocol, IGP) and is still in widespread use today (another example of IGP is Open Shortest Path First, OSPF). The version of RIP specified in RFC 1048 uses hop count as a cost metric, that is, each link has a cost of 1. RIP uses the term hop, which is the number of subnets traversed along the shortest path from source router to destination subnet, including the destination subnet. FIG. 6 shows a portion of an autonomous system.
The maximum cost of a path is limited to 15, thus limiting the use of RIP to autonomous systems that are fewer than 15 hops in diameter. In RIP, routing updates are exchanged between neighbors approximately every 30 seconds using a RIP advertisement.
Each router maintains a RIP table known as a routing table. A router's routing table includes both the router's distance vector and the router's forwarding table. The routing table has three columns. The first column is for the destination subnet, the second column indicates the identity of the next router along the shortest path to the destination subnet, and the third column indicates the number of hops to get to the destination subnet along the shortest path. Table 1 shows the routing table for router D of FIG. 6.
TABLE 1Number of hops from source router A to various subnetsDestination SubnetNext RouterNumber of Hops to DestinationwA2yB2zB7x—1. . .. . .. . .
Now suppose that 30 seconds later, router D receives from router A the advertisement shown in Table 2. This advertisement is nothing other than the routing table information from router A. This information, in particular, that subnet z is only four hops away from router A. Router D, upon receiving this advertisement, merges the advertisement with the old routing table. In particular, router D learns that there is now a path through router A to subnet z that is shorter than the path through router B. Thus, router D updates its routing table to account for the shorter shortest path, as shown in Table 2.
TABLE 2Advertisement from router ADestination SubnetNext RouterNumber of Hops to DestinationzC4w—1x—1. . .. . .. . .
TABLE 3Routing table in router D after receiving advertisement from router ADestination SubnetNext RouterNumber of Hops to DestinationwA2yB2zA5x—1. . .. . .. . .